There is an intermittent bug when calling RefsReceived() right after Init(). I'll have to work around that.

The intermittent bug seems unrelated to my changes since I can reproduce it on my other computer without these changes.

I like this version better because Koder always forks to the background unless --wait is used. Without this change, the first instance of Koder will always block even without --wait.

Reading data from stdin and sending it to the app might be complex and require a shared memory buffer or something, but that was already the case before this change.

I may end up closing this pull request and thinking about the problem more. I keep running into issues with whichever method I use. The most recent version is broken when being launched by Tracker and other apps.

It's possible Koder may need a small companion app to handle some command line options, similar to Pe/lpe.

I like this version better because Koder always forks to the background unless --wait is used. Without this change, the first instance of Koder will always block even without --wait.

What is the problem with this behavior? It's predictable - you want it to wait you use -w. EDIT: Unless I misunderstood and it currently blocks the first time - that's not how I remember coding it though.

It's possible Koder may need a small companion app to handle some command line options, similar to Pe/lpe.

I don't like the companion app solution because it's not very discoverable.

Can you document the issues you ran into here so it can be taken into account when changing this part of code.

What is the problem with this behavior? It's predictable - you want it to wait you use -w. EDIT: Unless I misunderstood and it currently blocks the first time - that's not how I remember coding it though.

Yes, it currently blocks the first time when --wait is not used.

Can you document the issues you ran into here so it can be taken into account when changing this part of code.

The short version is that it's difficult to fork the first instance of a BApplication into the background when launched by command line, while still allowing it to have access to any initial B_REFS_RECEIVED message when launched by GUI. I had a small conversation with waddlesplash in IRC to see if I could find a way around the problem.

12:39:40    augiedoggie | waddlesplash: do you know... if an app is launched with a refs received message, can the app get that message from main() before the
                        | BApplication is created?
12:40:00  @waddlesplash | off the top of my head I don't know
12:40:19  @waddlesplash | I never really looked into the mechanisms there
12:40:21    augiedoggie | can i fork before creating a BApplication and still have the message passed on?
12:41:07    augiedoggie | i think i tried that and it didn't work for some reason
12:43:15  @waddlesplash | a glance at the code, and it might depend on pre-registration
12:43:33  @waddlesplash | the parent after a fork will have the same team ID so will still be pre-registered
12:43:38  @waddlesplash | the child won't
12:43:39    augiedoggie | :/
12:43:46  @waddlesplash | what's the usecase?
12:44:11    augiedoggie | trying to get Koder to fork to the background consistently when it's started from the command line
12:44:33  @waddlesplash | well on the command line it doesn't get a refs message?
12:44:48    augiedoggie | right
12:45:24  @waddlesplash | I think realistically we need an "lkoder" or equivalent tool like "lpe"
12:45:25    augiedoggie | i can get it to work fine from the command line by using roster to launch the application in the background but the refs received
                        | message isn't passed on
12:45:36  @waddlesplash | "lpe" has the nice property that it doesn't quit until you close the Pe window that it opened
12:45:49  @waddlesplash | makes it suitable for use as an editor for various things like git
12:45:52    augiedoggie | heh, i mentioned that in the pull request and he's not fond of the companion app solution
12:46:01  @waddlesplash | well, I don't know any other way to do this
12:46:05    augiedoggie | yean :P
12:46:06  @waddlesplash | besides maybe a special switch
12:46:29    augiedoggie | i did the special switch thing but i still need a way to forward the initial bmessage
12:47:22    augiedoggie | right now Koder does have a --wait option which works ok-ish
12:47:58    augiedoggie | it's more of a personal annoyance that the first instance of the app will always block from the command line regardless of that switch
12:48:33  @waddlesplash | yes I agree
12:48:46  @waddlesplash | fork only on isatty()?
12:49:00    augiedoggie | i had that thought too but hadn't investigated it

I still need to do some testing and cleanup but the latest version works well. I would have preferred to do things a bit differently but I think it's acceptable.